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REMARKS 

Applicant has reviewed and considered the second Office Action dated June 18, 2002. 
Figure 2 is amended; claims 1, 15, 30 and 39 are amended. Claims 1-43 are pending in the 
present application. It is noted that although the pending Office Action makes reference to claim 
44, Applicant's response to the prior Office Action corrected the numbering of claims 38-44, 
renumbering them as claims 37-43, because no claim 37 existed in the claims as filed. Thus, 
claims 1-43 are pending. 

Attached hereto is a marked-up version of the changes made to the claims by the current 
amendment. The attached page is captioned "Marked-up Version Showing Changes.'' 

Claim Objection 

Claims 1,15, and 30 were objected to because of certain informalities. Claims 1,15, and 
30 are now amended to overcome the objections. 

Rejections under 35 U.S.C . . S 102(e) 

Claims 1, 15, and 30 were rejected under 35 U.S.C. § 102(e) as being anticipated by 
Yanagidate. Applicant respectfully disagrees with the rejection for at least the following 
reasons. 

Applicant's invention deals with communication between entities hi disparate address 
realms. They are disparate in that communication from one address realm to the other only 
occurs if a message sent across the boundary between the two realms has an address valid in the 
receiving realm. This can occur between two private networks that may have overlapping 
addresses, in which case an internal address in one private network must be made unique to be 
valid when it is used externally, i.e., in the other network. It can also occur between a private 
network with private or internal addresses and a public, external network, such as the Internet, in 
which unique and properly assigned IP addresses must be used. Thus, the terms "internal 
address" and "external address" refer to two different sides of a boundary between two disparate 
address realms, from the viewpoint of one side. The present invention focuses on an address 
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translation facility on one side of an address realm boundary and providing control services to 
the applications on the same side of such boundary. 

In the Internet context, the scarcity of externally valid EP addresses leads private and local 
networks to assign addresses valid only internally, i.e., within a local network, to applications 
running within that network. When such an application (e.g., Application A) needs to 
communicate with the global IP network, an externally valid or global IP address can be 
correlated with the internally valid address. The correlation is defined by a translation rule that 
is implemented in a conventional NAT (Network Address Translation) device, where the NAT is 
associated with the network where Application A runs. The NAT then translates Application 
A's external IP address inio its internal address on messages incoming to Application A and 
translates Application A's internal address into the assigned external address on messages 

outgoing from Application A. The address translation rule may be permanent but is more likely 

■ -\ 

temporary, to allow sharing of the limited external IP addresses. In a conventional NAT, 
Application A is assigned an external address only when the NAT determines the need. The 
conventional NAT determines the need and makes the assignment when it needs to handle an 
incoming or outgoing EP message packed. Application A can only send IP formatted message 
packets to the conventional NAT or receive them from the NAT. The conventional NAT makes 
the address translations, and also sets up a translation rule where one is needed and disca* r ds the 
rule when it is no longer needed. These operations are done automatically, without Application 
A's involvement or control. 

Yanagidate discloses essentially a conventional NAT device. More specifically, 
Yanagidate discloses an address translating connection device 14 that permits a device in a first 
network (reference no. 1, Fig. 1; reference no. 11, Fig. 2) employing global addresses to make an 
inquiry to obtain a global address of an internal terminal located in a second network (reference 
no. 2, Fig. 1; reference no. 12, Fig. 2) (see column 4, lines 13-16). The inquiry is made by 
designating the host name of the internal terminal and is sent from the first network. When an 
inquiry is received from the first network, the address translating connection device 14 takes 
steps to ensure that the private (internal) address correlated to the host name is also correlated to 
an available global address (column 2, line 55 to column 3, line 14). Accordingly, in 
Yanagidate, the inquiry is a request from the first network to an address translating connection 
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device associated with a second network to ask for a global address that already has been given 
to - or that in response to the inquiry may be given to — an internal terminal (or application) on 
the second network . In Yanagidate, the internal terminal (or application) on the second network 
is not involved in the initiation or selection of the translation rule that embodies the IP address 
assignment. 

On the other hand, in the claimed invention, a first application in a first address realm 
sends a service request message (not an outgoing packtt message) via a control channel to an 
address manager, requesting that an address valid in the second (external) address realm (e.g., 
Internet IP address) be assigned to the first application itself The requested external address will 
be associated with a specified internal address of the first application (valid in the first address 
realm, or "private" in Yanagidate" s terminology). The address manager not only assigns but 
provides the first application access to the requested external address (valid in the second address 
realm). This facilitates the first application's communication of the requested external address 
(valid in the second address realm) us message packet data to the second application. 
Accordingly, the request made by the first application and handled by applicant's address 
manager and control channel is to obtain an address valid in the second address realm to be 
associated with the first application's own specified internal (valid in the first address realm) 
address. The first application is provided a control channel to make the address request and gets 
access to its own external address. This permits the first application's communication of the 
external address (valid in the second address realm) as message packet data to the second 
application, which may be a peer application. That is, it also provides the first application 
control over communicating that address (see amended claim 30). 

Yanagidate fails to disclose or teach having an address manager receiving a service 
request via a control channel from a first application for assignment to such first (requesting) 
application of an external address (valid in the second address realm). In contrast to Applicant's 
invention, in Yanagidate the address-translating connection device handles an address request 
that comes from the second or external address realm. As stated in the Abstract: 

An address-translating connection device which makes it possible to dynamically assign 

an EP address to a private address when a connection is made to inside of a LAN from 

outside. 
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Yanagidate, Abstract, first sentence (emphasis added). In applicant's invention the first 
application that initiates dynamic address assignment is within the first address realm, i.e., inside 
the LAN, when the first address realm consists of a LAN. 

Yanagidate discloses an address -translating connection device for dealing with 
connections and address assignments initiated from outside of a LAN, not a system for 
empowering an application for making a service request by means of a control channel to its own 
NAT, i.e., to the NAT that performs address translation for message packets flowing into and out 
of the LAN on which that application resides. Providing an application with this control channel 
communicating with the address manager facilitates (among other things) peer-to-pesr 
application communication between disparate networks as disclosed in the present invention. 
There is no motivation or suggestion in Yanagidate that its address lookup table and IP address 
control table be used to establish a translation rule, except "when a connection is made to inside 
of a LAN from outside ." 

Accordingly, Applicant respectfully submits that claims 1,15, and 30 patentably 
distinguish over Yanagidate. 

The respective dependent claims rejected under 35 U.S.C. 102(e) in view of Yanagidate 
are distinguishable as well, a fo rtiori because of their additional features. With regard to 
dependent claims 2-3 and 16-17, it is submitted that Yanagidate only shows a single address for 
any terminal and therefore does not teach requesting either a terminating address or an 
originating address. 

With regard to claims 4-5 and 18-19, Yanagidate refers to first network 1 as employing 
global addresses and second network 2 as having a terminal 2a that has a private address 
(Yanagidate, col. 1 , line 46 to col. 2, line 20). Fig. 2 shows a similar configuration in which 
network 1 1 is described as the Internet, with network 12 being a LAN using private addresses. 
Because Yanagidate refers to the first network as the one using global addresses, Yanagidate's 
first network is network 1 or network 11. It is respectfully submitted that Yanagidate does not 
show the address realms as described in the rejection, but rather shows the reverse. The 
terminology is significant and not simply reversible, because in Yanagidate the first network is 
the only network that requests an address. 
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With regard to claims 9, 24 and 39 (we assume that claim 38, as renumbered, is meant, 
because it is parallel to claims 9 and 24), it is submitted that reference number 14a does not 
identify a terminal but rather a table in address translating device 14. Thus, the argument that 
"the communication between terminal 11a and terminal 14a uses the same IP protocol layer' ' has 
an incorrect foundation and cannot support the rejection. 

With regard to claims 13 and 14, parallel claims 28 and 29 and parallel claims 42 and 43 
(.is renumbered), it is submitted that Yanagidate has no teaching whatsoever of a forced address 
association with a destination address in a transit network, because no transit network is 
discussed, and further shows no forced communication through a specified network, because 
there arc no alternate networks available for specification. (We assume that the reference to 
claims 40-44 in the rejection is intended to refer to claims 39-43 as renumbered.) 

The remaining dependent claims not specifically discussed above are distinguishable for 
at least the same reasons as independent claims 1,15 and 30. Note that former claim 39, now 
claims 38, has been amended to make its language consistent with claim 30. 

Reconsideration and withdrawal of all rejections based on 35 U.S.C. 102(e) in view of 
Yanagidate is respectfully requested. 

Rejection under 35 U.S.C . £ 103 

Claims 7-8, 21-23, and 36-38 (presumably claims 36-37 as renumbered were intended) 
are rejected under 35 U.S.C. § 103(a) as being unpatentable over Yanagidate. Claims 7-8, 21- 23, 
and 36-38 are dependent from claims 1,15, and 30, respectively. In addition to the reasons 
discussed above, claims 7-8, 21-23, and 36-38 are patentable over Yanagidate, because these 
claims cover certain contingent and variable address translation rules. In applicant's invention 
the presence of specified originating address information in an inbound message packet may 
affect the address manager's behavior in establishing or using translation rules. 

In the Office Action, the Examiner conceded that Yanagidate fails to disclose 
establishing rules for translation of address information in an inbound message packet to occur in 
response to the presence or absence of specified originating address information in the message 
packet. However, the Examiner contended that it is well known in the art that an IP packet 
comprises at least a source address and a destination address in its header; and that "it would 
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have been obvious to one having ordinary skilled in the art at the time the invention was made to 
check the source address of the incoming packet to determine whether the user have access to the 
private network or secure network - thus preventing hackers or unwanted users from gaining 
access to the private network". No prior art is cited to support this statement. Even if it were 
supported, the bare concept of checking the source address does not mean that it would be 
obvious to effect security by establishing NAT translation rules, in particular the contingent 
translation rules responsive to originating address information of the kind Applicant teaches and 
claims. 

Applicant respectfully submits that there is no teaching, suggestion, or motivation in 
Yanagidate to establish a translation rule or establish a contingent/alternative translation rules 
responsive to a check of the source address of the incoming packet. Yanagidate's address 
translation connection device functions merely based on a fixed, simple translation rule, 
embodied in a table. Only by hindsight and speculation, after appreciating the gist of the present 
invention, can it be argued that Yanagidate address translation connection device suggests a 
translation rule responsive to the results of checking of the source address of the incoming 
packet to determine whether the user should have access to the private network or secure 
network. Applicant respectfully submits that such hindsight and speculation is nor proper. 
Accordingly, Applicant respectfully requests that the Examiner withdraw the under rejection of 
claims 7-8, 21-23, and 36-38 (claims 36-37 as renumbered} based on obviousness. 



Conclusion 

In view of the above, it is respectfully submitted that the present application is in 
condition for allowance. Reconsideration of the present application and a favorable response are 
respectfully requested. 
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If a telephone conference would be helpful in resolving any remaining issues, please 



contact the undersigned at (612)340-2734. 



Date: 



Respectfully submitted, 
DORSEY & WHITNEY LLP 




Stuart R. Hemphill (Reg. No. 29,084) 

Suite 1500 

50 South Sixth Street 

Minneapolis, MN 55402-1498 

(612) 340-2734 

Attorneys for Applicant 
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MARKED-UP VERSION SHOWING CHANGES 



IN THE CLAIMS 



Please amend claims 1, 15, 30 and 38 as follows: 
1 . (Twice Amended) A network address translation device for facilitating message packet 
communication between a first application having an internal address valid in a first address 
realm and a second application in a second address realm comprising: 

an address translator for translating [an] the internal address valid in the first address 
realm into an address valid in the second address realm based on a translation rule and for 
translating the address valid in the second address realm into the internal address valid in the first 
address realm; 

an address manager for establishing [a] the translation rule by associating [an] the 
internal address valid in the first address realm with [an] the address valid in the second address 



a control channel communicating with the address manager for receiving from the fet 
application a service request message for [an] the address valid in the second address realm to be 
associated with [a specified] the internal address of the first a p plication valid in the first address 
realm and for providing the first application access to the requested address valid in the second 
address realm to facilitate the first application's communication of the address valid in the 
second address realm as message packet data to the second application. 

15. (Twice Amended) A method for facilitating message packet communication between a first 
application having an internal address valid in a first address realm and a second application in a 
second address realm comprising: 

providing the first address realm with a network address translation device having an 
address translator for translating [an] the internal a ddress of the first application valid in the first 
address realm into an address valid in the second address realm based on a translation rule and 
for translating the address valid in the second address realm into the internal address valid in the 
first address realm; 



realm; and 
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providing an address manager in communication with the address translator for 
establishing [a] the translation rule by associating [an] the internal address valid in the first 
address realm with [an] the address valid in the second address realm; 

providing a control channel communicating with the address manager; 

receiving at the address manager from the first application via the control channe l a 
service request message for [an] the address valid in the second address realm to be associated 
with [a specified] the internal address of the first application valid in the first address realm; and 

providing the first application access to the address valid in the second address realm to 
facilitate the first application's communication of the address valid in the second address realm 
as message packet data to the second application. 

30. (Twice Amended) A system for establishing message packet communication between a first 
application having an internal address valid in a first address realm and a second application in a 
second address realm, wherein the first address realm has an address translator for translating 
[an] the internal address o f the first application valid in the first address realm into an address 
valid in the second address realm based on a translation rule and for translating the address valid 
in the second address realm into the internal address valid in the first realm, comprising: 
an address manager for establishing [a] the translation rule by associating [an] the 
internal address valid in the first address realm with [an] the address valid in the second address 
realm; 

a control channel communicating with the address manager; and 
software operatively associated with the first application for communicating to the 
address manager via th e control channel a service request message for [an] the address valid in 
the second address realm to be associated with [a specified] the internal address of the first 
application valid in the first address realm, for receiving access to the requested address valid in 
the second address realm, and for controlling communication of [communicating] the address 
valid in the second address realm [as message packet data to the second application]. 
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38. (Renumbered, then amended) The system of claim 30, wherein the software controls 
communication of the address valid in the second address realm to facilitate [facilitated is] peer- 
to-peer application communication. 
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